Node / dev / reticulum / files / docs / markdown / git.md

Displaying Rendered • View raw • Download

A set of utilities for distributed collaborative software development and publishing are included in RNS.

The system consists of two parts: The T383838rngit node that hosts repositories, and the T383838git-remote-rns helper that enables Git to communicate with rngit nodes. As soon as you have RNS installed on your system, you can transparently use Git with Reticulum-hosted repositories just like any other type of remote. Git over Reticulum uses URLs in the following format: T383838rns://DESTINATION_HASH/group/repo.

If you set a branch to track a Reticulum remote as the default upstream, you can simply use T383838git as you normally would; all commands work transparently and as expected.

The rngit program is a new addition to RNS! This functionality was introduced in RNS 1.2.0. While great care has been taken to design a secure, but highly configurable and flexible permission system for allowing many users to interact with many different repositories on a single node, T383838rngit has not been tested extensively in the wild! Be careful when hosting repositories, especially if they are public or semi-public.

The T383838rngit utility provides full Git repository hosting and interaction over Reticulum. It allows you to host and manage Git repositories and releases on Reticulum nodes, and to interact with remote repositories using standard Git commands through the T383838rns:// URL scheme.

Run T383838rngit to start a repository node:

T282828

On the first run, T383838rngit will create a default configuration file. You will then need to edit this, to point to your repository locations, configure access permissions, and perform any other necessary configuration.

Them, view your identity and destination hashes:

T282828

If the page node is enabled, the output will also include the Nomad Network destination hash.

You can run T383838rngit in service mode with logging to file:

T282828

Clone a repository from a remote T383838rngit node:

T282828

Add a Reticulum remote to an existing repository:

T282828

Push changes to the Reticulum remote:

T282828

Get changes from a remote repository:

T282828

Fork an existing repository from a remote to your T383838rngit node:

T282828

T282828

The T383838git-remote-rns helper is automatically invoked by Git when interacting with T383838rns:// URLs. It is not typically run directly by users, but accepts the following environment variables for configuration:

• T383838RNGIT_CONFIG - Path to alternative client configuration directory

• T383838RNS_CONFIG - Path to alternative Reticulum configuration directory

The client configuration file is located at T383838~/.rngit/client_config and allows adjusting parameters such as the reference batch size for transfers.

The T383838rngit utility provides several ways to create and manage repositories on a node: creating empty repositories, forking from existing repositories, and mirroring remote repositories.

To create a new empty repository on a remote node:

T282828

This creates a bare Git repository at the specified path. You must have T383838create permission for the target group. When a repository is created, the creator automatically receives T383838adm (admin) permissions on the repository through an auto-generated T383838.allowed file.

T282828

Forking creates a copy of an existing repository (from any accessible Git URL) on your T383838rngit node. Forks maintain a reference to their upstream source for later synchronization.

To fork a repository:

T282828

The source can be any valid Git URL, including:

• HTTPS URLs: T383838https://github.com/user/repo.git

• Git URLs: T383838git://host.com/repo.git

• SSH URLs: T383838ssh://git@host.com/repo.git

• Reticulum URLs: T383838rns://DESTINATION_HASH/group/repo

• Local paths: T383838/path/to/repo.git

Forks are created as bare repositories with metadata tracking their origin. The fork process:

1. Creates a new bare repository

2. Fetches all refs (T383838+refs/*:refs/*) from the source

3. Sets T383838repository.rngit.type to T383838fork

4. Sets T383838repository.rngit.upstream.source to the source URL

5. Grants creator admin permissions

T282828

Mirrors are similar to forks but are designed for keeping a local copy synchronized with an upstream repository. Mirrors can be automatically updated on a configurable schedule.

To create a mirror:

T282828

Mirrors are created with the same process as forks, but with T383838repository.rngit.type set to T383838mirror and an additional T383838repository.rngit.upstream.sync timestamp tracking the last successful synchronization.

T282828

The T383838rngit node can automatically keep mirrors synchronized with their upstream sources. This is configured in the main configuration file:

T282828

The T383838mirror_interval specifies the synchronization interval in hours (default: 24). The node checks for mirrors needing sync every 15 minutes, and fetches updates from upstream if the configured interval has elapsed since the last sync.

For automatic sync to happen, the repository must have been created with T383838rngit mirror. Sync failures are logged but do not prevent future retry attempts. The sync timestamp is only updated on successful completion.

Both forks and mirrors can be manually synchronized on demand using the T383838sync command:

T282828

This fetches all refs from the upstream source configured when the repository was created. You must have T383838read and T383838write permissions for the repository to perform a manual sync.

For mirrors, manual sync also updates the sync timestamp, effectively resetting the automatic sync timer.

T282828

Repositories created through T383838rngit store metadata in Git configuration:

• T383838repository.rngit.type - Either T383838fork or T383838mirror

• T383838repository.rngit.upstream.source - The source URL used during creation

• T383838repository.rngit.upstream.sync - Unix timestamp of last successful sync for mirrors

These parameters are used by the sync system and can be queried using standard Git commands:

T282828

The T383838rngit node organizes repositories into groups. Each group is a directory containing bare Git repositories. The repository path format is T383838group_name/repo_name. For example, a repository at T383838/var/git/public/myrepo would be accessible as T383838public/myrepo via the URL T383838rns://DESTINATION_HASH/public/myrepo.

The T383838rngit node configuration file is located at T383838~/.rngit/config (or T383838/etc/rngit/config for system-wide installations). The default configuration includes:

• Repository group paths defining where to find bare repositories

• Access permissions for groups and individual repositories

• Announce intervals for network visibility

• Optional statistics recording for repository activity

The T383838rngit permission system provides fine-grained access control at multiple levels: group-level, repository-level, and document-level. Permissions can be statically configured in files or dynamically generated via executable scripts.

Access permissions can be configured at the group level in the config file or per-group T383838.allowed files, or per-repository T383838.allowed files. The T383838s (stats) permission allows viewing repository activity statistics, including views, fetches and pushes over time. To enable statistics recording, set T383838record_stats = yes in the T383838[rngit] section of the configuration file. You can also exclude specific identities from statistics by adding their hashes to T383838stats_ignore_identities.

By default, no permissions are granted for anything! You will have to enable the permissions you require to be able to actually do something with T383838rngit.

The following permissions are supported:

• T383838r (read) - Clone, fetch, and view repositories and work documents

• T383838w (write) - Push changes and manage work documents

• T383838rw (read/write) - Combined read and write access

• T383838c (create) - Create, fork or mirror new repositories within a group

• T383838s (stats) - View repository activity statistics

• T383838rel (release) - Create and manage releases

• T383838i (interact) - Comment on and interact with work documents

• T383838p (propose) - Propose new work documents (without full write access)

• T383838adm (admin) - Full access

Permission targets can be:

• T383838all or T383838a - Everyone

• T383838none or T383838n - Nobody

• A specific Reticulum identity hash

Permissions are resolved in the following hierarchy:

1. Repository-level permissions - Checked first, if none exists group permissions are checked

2. Group-level permissions - Used as fallback if no repository-level permissions are set

3. Admin override - Finally, potential admin rights are checked

For work documents, work document specific permissions are always checked first, and work documents have additional specific checks such as modifications only being possible by the document author.

Group permissions can be configured in the T383838[access] section of the main config file:

T282828

Additionally, they can be configured in a group T383838group_name.allowed file, placed next to the T383838group_name group directory.

Repository-specific permissions are set in T383838.allowed files placed next to the repository directory (for example, T383838myrepo.allowed for T383838myrepo):

T282828

Permission files can be made executable to generate permissions dynamically:

T282828

When executable, the script is run and its stdout is parsed as permission rules. This allows integration with external authentication systems.

Work documents support additional permission granularity through T383838.allowed files in the work directory (e.g., T38383842.allowed for document #42). These files use the same permission syntax but only support:

• T383838r (read) - View the document

• T383838w (write) - Edit the document

• T383838i (interact) - Comment on the document

• T383838p (propose) - Propose changes (future use)

• T383838adm (admin) - Full control over the document

Document permissions override repository permissions for that specific document. Work document permissions can be updated simply by editing the T383838.allowed file, or remotely by using the T383838rngit work command.

When a user creates a repository (via T383838create, T383838fork, or T383838mirror), they are automatically granted T383838adm (admin) permissions on that repository.

When a user creates a work document, they automatically receive T383838interact and T383838write permissions on that document.

T282828

Everyone can read, only the specified identity can write.

T282828

Everyone can read, interact (comment), and propose work documents. Only the specified identity can write, create releases, and manage work documents fully.

T282828

Only the two specified identities have any access (read or write).

T282828

Everyone can read and view stats, but nobody can push (mirror is read-only from upstream).

Permissions can be specified using short or long forms:

• T383838r = T383838read

• T383838w = T383838write

• T383838rw = T383838readwrite

• T383838c = T383838create

• T383838s = T383838stats

• T383838rel = T383838release

• T383838i = T383838interact

• T383838p = T383838propose

• T383838adm = T383838admin

Targets can also use short forms:

• T383838a = T383838all = T383838everyone

• T383838n = T383838none = T383838nobody

• User install: T383838~/.rngit/config

• System install: T383838/etc/rngit/config

• Group permissions: T383838<group_root>/<group_name>.allowed

• Repository permissions: T383838<group_root>/<group_name>/<repo_name>.allowed

• Document permissions: T383838<group_root>/<group_name>.work/<doc_id>.allowed

In addition to providing Git repository access via the Git remote helper protocol and command-line tools, T383838rngit can also run a Nomad Network compatible page node. This allows users to browse repository information, view file contents, inspect commit history and access repository statistics through any Nomad Network client.

When enabled, the page node provides a complete interface to your repositories, with automatic Markdown to Micron conversion, syntax-highlighted code browsing, and detailed commit, diff and statistics views.

To enable the page node, add the following to your T383838~/.rngit/config file:

T282828

When the page node is enabled, T383838rngit will listen on a Nomad Network node destination in addition to the Git repository destination. You can view the destination hash by running:

T282828

Once the page node is running, you can access it from any Nomad Network client by connecting to the Nomad Network destination. The page node provides the following views:

• Front Page - Lists all repository groups accessible to your identity

• Group Page - Shows all repositories within a group

• Repository Page - Displays repository overview, description and README

• Releases - List of releases for the repository, with information and downloads

• File Browser - Browse directory trees and view and download file contents

• Commits View - View commit history with pagination

• Commit Details - Detailed commit information with file changes and diffs

• Refs View - List branches and tags

• Statistics - Activity charts showing views, fetches and pushes over time

All pages respect the same permission system used for Git access. If an identity does not have read access to a repository, they will not be able to view its pages.

If the T383838pygments Python module is installed on your system, the page node will automatically apply syntax highlighting to code files. The highlighting supports a wide range of programming languages and uses a color theme optimized for terminal display.

To enable syntax highlighting, install pygments:

T282828

README files and other Markdown documents are automatically converted to Micron markup for display in Nomad Network clients. You can also write your README files directly in Micron, in which case they will display and render as such in any Nomad Network client. The file browser also supports viewing both rendered and raw Markdown and Micron documents.

Code blocks in Markdown can include language hints for syntax highlighting:

def hello_world():

print("Hello, Reticulum!")

The page node uses a template system that allows complete customization of the generated pages. Templates are stored in the T383838~/.rngit/templates/ directory as Micron files.

The following template files are supported:

• T383838base.mu - Base template wrapping all pages

• T383838front.mu - Front page listing all groups

• T383838group.mu - Group page listing repositories

• T383838repo.mu - Repository overview page

• T383838releases.mu - Release list page

• T383838release.mu - Release details page

• T383838tree.mu - File browser pages

• T383838blob.mu - File content display

• T383838commits.mu - Commit history listing

• T383838commit.mu - Individual commit detail page

• T383838refs.mu - Branches and tags listing

• T383838stats.mu - Statistics page

Templates can include the following variables:

• T383838{PAGE_CONTENT} - The main content of the page (required)

• T383838{NODE_NAME} - The configured node name

• T383838{NAVIGATION} - Breadcrumb navigation links

• T383838{VERSION} - The rngit version number

• T383838{GEN_TIME} - Page generation time

Templates can be made executable to generate dynamic content. If a template file has the executable bit set, it will be executed and its stdout used as the template content.

By default, the page node uses Nerd Font icons. If you prefer simpler icons or your terminal does not support Nerd Fonts, you can enable Unicode icons instead:

T282828

When statistics recording is enabled (see the T383838record_stats configuration option), the page node can display activity charts for each repository. The statistics page shows:

• Total and peak views, downloads, fetches and pushes

• Daily activity charts over a 90-day period

• Combined activity visualization

To view statistics, a user must have the T383838s (stats) permission for the repository. See the Access Configuration section for details on setting permissions.

The page node includes a “Thanks” feature that allows users to express appreciation for a repository. On each repository page, a “Thanks” link is displayed showing the current thanks count. Clicking this link registers a thank you for the repository.

A complete node configuration might look like this:

T282828

In addition to hosting Git repositories, T383838rngit provides a complete release management system. This allows you to publish versioned releases with associated artifacts, release notes and metadata. Releases are managed through the T383838rngit release subcommand, and are also viewable through the Nomad Network page interface.

Creating a release involves specifying a Git tag and a directory containing build artifacts or other files to distribute. The T383838rngit client will open your configured T383838$EDITOR to compose release notes, then upload all artifacts to the remote repository node.

To create a release, specify the tag name and path to artifacts:

T282828

This will:

1. Verify that the tag T383838v1.2.0 exists in the repository

2. Open your editor to write release notes

3. Upload all files from the T383838./dist directory

4. Publish the release

If no T383838$EDITOR environment variable is set, T383838rngit will try to use T383838nano, T383838vim or T383838vi. The editor will show a template with instructions. Lines starting with T383838# will be ignored, and if the remaining content is empty after stripping comments, the release creation will be cancelled.

Releases are stored on the node in a directory named T383838repo_name.releases next to the bare repository. Each release is a subdirectory containing:

• T383838META - Release metadata in ConfigObj format

• T383838RELEASE.md or T383838RELEASE.mu - Release notes

• T383838artifacts/ - All uploaded files

• T383838THANKS - Appreciation count from users

To view all releases for a repository:

T282828

To see full information about a specific release:

T282828

To remove a release:

T282828

• The specified tag must exist in the remote repository

• You must have T383838release permission for the repository

• The target artifacts directory must exist and contain at least one file

• Release notes cannot be empty

Release management requires the T383838release permission, configured the same way as other repository permissions. In the config file or T383838.allowed files, use T383838rel:target to grant release management rights:

T282828

When the Nomad Network page node is enabled, releases are displayed on a dedicated releases page for each repository. Each release is listed with its tag, creation date, artifact count and a preview of the release notes. Clicking a release shows the full details including formatted release notes and a listing of all artifacts with their sizes.

T282828

In addition to releases, T383838rngit provides a work document management system for tracking tasks, investigations, issues and progress related to repositories. Work documents are stored as structured msgpack data and support threaded updates and comments.

To view work documents for a repository:

T282828

Use T383838--scope completed to view completed work documents, T383838--scope proposed to view proposed documents, or T383838--scope all to see all scopes.

To view a specific work document with all its comments:

T282828

To create a new work document:

T282828

This will open your configured T383838$EDITOR to compose the document content. Save and exit to create the document, or save an empty document to cancel.

To edit an existing work document:

T282828

This fetches the current content, opens it in your editor, and sends any changes back to the node.

To add an update to a work document:

T282828

This opens your editor to compose the update.

Users with T383838propose permission can create work document proposals without full T383838write access. Proposals are created in a “proposed” state and must be activated by a user with appropriate permissions before becoming active.

To propose a work document:

T282828

This opens your editor to compose the proposal content. When saved, the document is created in the “proposed” scope. The creator automatically receives T383838interact and T383838write permissions on the proposed document.

Proposed documents are visible through T383838--scope proposed or T383838--scope all:

T282828

• Creating proposals requires T383838propose permission on the repository

• The creator automatically gets T383838interact and T383838write on their proposed document

• Activating a proposal requires T383838write and T383838interact permissions

To mark a work document as completed (moving it from T383838active to T383838completed):

T282828

To mark a work document as active (moving it from T383838completed to T383838active):

T282828

To delete a work document and all its comments:

T282828

Users with administrative access to a work document can manage its specific permissions. This allows fine-grained control over who can read, write, comment on, or administer individual work documents.

To view or edit permissions for a work document:

T282828

This opens your editor with the current permission configuration:

T282828

Permission rules follow the same format as repository permissions:

• T383838r:target - Grant read access

• T383838w:target - Grant write access

• T383838i:target - Grant interact (comment) access

• T383838adm:target - Grant admin access

Targets can be T383838all, T383838none, or a specific identity hash.

Document permissions can be edited by:

• The original author (if they also have T383838interact and T383838write on the repository)

• Any user with T383838admin permission on the document

• Repository admins (through inherited permissions)

Document-specific permissions override repository-level permissions for that document. If document permissions exist, they are checked first; if access is not granted there, repository permissions are checked.

• Users can only edit or delete work documents they created

• The author is cryptographically verified from the interacting link’s T383838remote_identity

• Document creators automatically receive T383838interact and T383838write on their documents

Work documents are stored in a T383838repo_name.work directory next to the repository, containing:

• T383838active/ - Active work documents

• T383838completed/ - Completed work documents

• T383838proposed/ - Proposed work documents

Each document is a numbered directory containing:

• T383838root - The work document content and metadata (msgpack format)

• T383838N - Numbered comment files (msgpack format)

When the Nomad Network page node is enabled, work documents are viewable through the web interface. The work page lists all documents with their status, and clicking a document shows its full content and updates.

T282828